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ABSTRACT 



The Universal Plug and Play architecture contemplates 
devices and control points that can automatically integrate 
themselves into a network and provide functionality to a 
user. Extensions are provided that allow an^ information 
presentation appliance to identify categories of information 
the user wishes that appliance to display. The appliance, 
acting as a device, can advertise functionality that only 
allows for the display of information that matches the 
categories selected by the user. Alternatively, the appliance 
can act as a control point and request information from 
information storage devices that matches the categories 
selected by the user. Using either alternative, the user is 
allowed to tune, at the appliance, the information that the 
appliance presents. 
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TUNABLE INFORMATION PRESENTATION 
APPLIANCE USING AN EXTENSIBLE MARKUP 
LANGUAGE 

TECHNICAL FIELD 

[0001] The invention relates generally .to providing a 
mechanism to allow a user to tune an information presen- 
tation appliance and, more particularly, relates to extending 
a profile of a self -configuring information presentation 
appliance through the use of an extensible markup language. 

BACKGROUND OF THE INVENTION 

[0002] An increasing number of common household items 
are evolving into computing machines capable of network 
communication. The goal of such an evolution is to allow 
appliances throughout a home to communicate with one 
another so that the user can simplify his or her lifestyle. For 
example, many common household items, including ovens, 
microwaves, video devices, radios and alarm clocks each 
contain a time display. However, because such appliances 
cannot currently communicate with one another, the user is 
forced to set the correct time on each appliance. Inter- 
appliance communication would allow a single appliance to 
share the correct time with all of the other appliances, 
minimizing the effort on the part of the user. Such efficien- 
cies, however, require creating and managing a communi- 
cations network connected to many different appliances. 

[0003] To ease the burden of setting up a communication- 
capable appliance and integrating it into such a network, a 
number of technologies and protocols have been developed 
which allow appliances to configure themselves. One such 
technology is known as Universal Plug and Play (UPnP) and 
defines a mechanism by which an appliance can automati- 
cally learn of other appliances and integrate itself into the 
network. The UPnP^chitecture"defines-two;categories-for 
appliances: a "device " categoryrcontaining thoserappliancesj 
which can-rej^e^^tructic^ 

"control pomflcategc^yjorjhpse.appliances which caasencb 

iristr^fions:and;thereby^ 

advertise-Uie^servicl^—iF 

b ro1idc!sTing : aliK ^ 

vvorlc-to^wBich-itcis-attachedi The message containing the 
services can be detected by a e UPnP-control~point and, if the 
control point is interested in the services exposed by the 
device, it can query the device for further information 
regarding those services and learn how to control those 
services. 

[0004] From the perspective of the user, UPnP devices and 
control points are setup- free: the user merely plugs them into 
the communication network, and the appliances configure 
themselves. Thus, a user having a UPnP compliant oven, 
microwave, video device, radio and alarm clock need not 
spend the time and effort to determine the correct time and 

_ set the time on each appliance^ rjsteadcthe-userzcanzsimply 
attach a-contrbl^iritfsu^^ 

crcontrol-point-will-leara^of-each-device^connectedztozthe 
c communication=netwo rkr LAsingle-instniction-fromrth^user 

c tO:a: control-point can:be:used:to set the:correct ; time_on.each 
devicepsaving-the-user-from-th^bu^ each 
^separately. 



[0005] However, the current UPnP implementation does 
not provide any mechanism by which a device or control 
point can automatically tune or filter the information it 
displays to the user. For example, a device is Limited by its 
functionality to displaying whatever information it is pro- 
vided by a control point. fThusPan-LGD-pictureiframe^for 
crexample~ will display all of the pictuTeTseht to it by:a control 
-point;:and:a:speaker,:such:jas^r^ 

~play whatever-audio datrit receives frblrrFcontrol-pointTA' 
a>n^ol : pbin^ 

me^pjcmre-fratne^ orztheraudio -sent-to-tbe-speaker^for- 
example^burit^ec^ 

Thus, a user seeking to send one set of pictures to an 
electronic picture frame in a home office, and another set to 
an electronic picture frame in a family room must explicitly 
define each set at the control point and direct each set to a 
particular picture frame. If the user subsequently moves the 
picture frame from the home office into the bedroom, the 
user is forced to explicitly define a new picture set for the 
bedroom at the control point, and direct it to the picture 
frame now located there. Similarly, if the user has a personal 
computer set up as a control point, with a broadband 
connection to a network such as the Internet, through which 
the user receives digital radio stations, the user will be 
forced to select the radio stations played by the speaker at 
the control point instead of at the speaker. Ultimately, the 
user is continually forced to perform any tuning of the 
content presented on their own and only at the control point. 

SUMMARY OF THE INVENTION 

[0006] The present invention, therefore, is directed to a 
method, system, and apparatus which allow a user to rune 
the content presented on an intelligent information presen- 
tation appliance. 

[0007] The present invention is also directed to a method, 
system, and apparatus which allow appliances that tradition- 
ally acted as devices to act as control points within the UPnP 
network structure. 

[0008] The present invention is additionally directed to a 
method, system, and apparatus which allow the definition of 
a device or a control point within the UPnP network struc- 
ture to be extended via an extensible markup language such 
as XML. 

[0009] The present invention provides a tuning capability 
for information presentation appliances by extending the 
definition of the appliance, whether it is a UPnP device or 
control point. The appliance can contain a user interface, in 
either hardware or software, for tuning the information 
presented by the appliance. An extension to a standardized 
XML schema is contemplated, wherein the additional ele- 
ments represent categories of information from which the 
user can select. In such a manner, the user's tuning can be 
transmitted through XML pages which remain backwards 
compatible. If the appliance is a control point, the user's 
tuning can be detected and represented in an extended XML 
schema so that the control point can instruct information 
sources, such as compatible Internet radio station servers or 
image servers, to send only specific categories of informa- 
tion reflecting the user's tuning. If the appliance is a device, 
it can advertise its methods, through an extended XML 
schema, as being capable of presenting only those categories 
of information reflecting the user's tuning. To devices and 
control points which do not contain the functionality of the 
present invention, the extensions to the XML schemas 
contemplated by the present invention are ignored, thereby 
ensuring backwards compatibility with older devices. 
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[0010] Additional features and advantages of the inven- 
tion will be made apparent from the following detailed 
description of illustrative embodiments which proceeds with 
reference to the accompanying figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] While the appended claims set forth the features of 
the present invention with particularity, the invention, 
together with its objects and advantages, may be best 
understood from the following detailed description taken in 
conjunction with the accompanying drawings of which: 

[0012] FIG. 1 is a block diagram generally illustrating an 
exemplary display apparatus for use with the present inven- 
tion; 

[0013] FIG. 2 is a block diagram generally illustrating an 
exemplary computing device for use with the present inven- 
tion; 

[0014] FIG. 3 is a cross-sectional diagram generally illus- 
trating a home in which the present invention can be used; 

[0015] FIG. 4 is a block diagram generally illustrating a 
series of communications common in an architecture with 
which the present invention can be used; 

[0016] FIG. 5 is a block diagram generally illustrating a 
series of communications contemplated by the present 
invention; 

[0017] FIG. 6 is a block diagram generally illustrating a 
series of alternate communications contemplated by the 
present invention; and 

[0018] FIG. 7 is a user interface diagram generally illus- 
trating an exemplary user interface contemplated by the 
present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0019] The present invention is directed to a method, 
system, and apparatus for providing tuning ability to appli- 
ances which present content to a user. A audio and/or video 
presentation appliance, such as an electronic picture frame 
(EPF), television, decoder device, set-top box, stereo sys- 
tem, radio, and the like, can be directly tuned by a user 
through the selection of categories of information presented 
through a user interface. Following a standard Universal 
Plug and Play (UPnP) architecture, the present invention 
contemplates extensions to the extensible Markup Lan- 
guage (XML) schemas used to define a device and the 
services exposed by that device. A control point can use 
these extensions to determine the categories of information 
which can be presented to the user through the device. The 
user can then select from amongst these categories, thereby 
tuning the information presentation appliance. Alternatively, 
the user can select from a predefined set of categories and 
the device can create a device description that advertises the 
device as capable of presenting the selected categories. The 
device will, thereby, receive only those categories of infor- 
mation from an information store at a control point, or 
through a control point. In either case, the user is not 
required to pre-define the information that can be delivered 
to an information presentation appliance from an informa- 
tion store, but can tune the appliance as desired. 



[0020] Turning to the drawings, wherein like reference 
numerals refer to like elements, the invention is illustrated as 
being implemented in a suitable computing environment. 
Although not required, the invention will be described in the 
general context of computer-executable instructions, such as 
program modules, being executed by a computing device. 
Generally, program modules include routines, programs, 
objects, components, data structures, etc. that perform par- 
ticular tasks or implement particular abstract data types. 
Moreover, those skilled in the art will appreciate that the 
invention may be practiced with many different computer 
system configurations, including hand-held devices, multi- 
processor systems, microprocessor based or programmable 
consumer electronics, network PCs, minicomputers, main- 
frame computers, intelligent appliances, and the like. The 
invention may also be practiced in distributed computing 
environments where tasks are performed by remote process- 
ing devices that are linked through a communications net- 
work. In a distributed computing environment, program 
modules may be located in both local and remote memory 
storage devices. 

[0021] FIG. 1 illustrates an example of an intelligent 
appliance for use with the present invention. An information 
presentation appliance 1 can either present information to a 
user through a video device 2 or a sound device 3. The video 
device can be a television, an LCD panel, an EPF, a 
projection screen, or the like. Similarly, the sound device 3 
can be a speaker, a stereo system, a radio, or other sound 
transducer. While it is possible that a single information 
presentation appliance 1 can have both audio and video 
output, such as a television set, it is also contemplated that 
the information presentation appliance can have only one, 
such as a simple, low-cost, EPF. Furthermore, it is not 
intended that the present invention be limited to information 
presentation appliances which can only deliver information 
through sound or audio. For example, an information pre- 
sentation appliance 1 can be a decoder device or set-top box. 
As is know by one of skill in the art, such devices do not 
provide direct audio or video output to a user, but instead 
decode one signal and present it in another format to another 
information presentation appliance. The present invention 
contemplates information presentation appliances, such as 
decoder devices, or set-top boxes, which can receive infor- 
mation over a network, as will be described in detail below, 
and present it in a common format, such as an interlaced 
video stream, or an pre-amplified audio stream to a less 
sophisticated information presentation appliance, such as a 
common TV or stereo system. 

[0022] The information presentation appliance 1 can be 
connected to a UPnP network 4, which will be described in 
further detail below, through a network interface 5. A 
processing unit 6 can perform the steps required by the 
present invention and, in the process, can use the system 
memory 7, which can be volatile and/or nonvolatile memory 
such as read only memory (ROM) 8 and random access 
memory (RAM) 9. A basic input/output system (BIOS) 10, 
can contain the basic routines that help to transfer informa- 
tion between elements within the information presentation 
appliance 1, such as when the appliance is turned on or 
plugged into an electrical outlet. Such BIOS 10 is typically 
stored in ROM 8, together with a minimal.operating system 
11 which can contain the necessary interfaces to enable the 
operation of higher level programs or instructions. RAM 9 
typically contains data and/or program modules that are 
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immediately accessible to and/or presently being operated 
on by processing unit 6. The program modules 12 and 
program data 13 can contain the necessary information to 
operate the appliance 1, and enable the appliance to com- 
municate over the network 4. 

[0023] As the invention is directed to the ability of a user 
to tune the content which is displayed by an appliance, such 
as information presentation appliance 1, the information 
presentation appliance can contain an input interface 16 for 
accepting user input. A variety of user input devices can be 
used, such as a mouse 17, a keyboard 18, or built-in devices, 
such as a touch-screen or a jog-dial, not shown. Generally, 
the type of input device will be determined by the intended 
use of the information presentation appliance 1, and its 
target cost. The input interface 16 can communicate with the 
other elements of the information presentation appliance 1 
though a system bus 19. The system bus 19 can be any type 
of bus structure including a memory bus or memory con- 
troller, a peripheral bus, and a local bus using any of a 
variety of bus architectures, including wire-based and wire- 
less architectures. 

[0024] FIG. 2 illustrates an example of a suitable com- 
puting device 20 with which the invention may be imple- 
mented. The computing device 20 is only one example of a 
suitable computing environment and is not intended to 
suggest any limitation as to the scope of use or functionality 
of the invention. Neither should the computing device 20 be 
interpreted as having any dependency or requirement relat- 
ing to any one or combination of components illustrated in 
the exemplary computing device 20. Components of the 
computing device 20 may include, but are not limited to, a 
processing unit 21, a system memory 22, and a system bus 
23 that couples various system components including the 
system memory to the processing unit 21. The system bus 23 
may be any of several types of bus structures including a 
memory bus or memory controller, a peripheral bus, and a 
local bus using any of a variety of bus architectures includ- 
ing wire-based and wireless architectures. By way of 
example, and not limitation, such architectures include 
Industry Standard Architecture (ISA) bus, Micro Channel 
Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video 
Electronics Standards Associate (VESA) local bus, and 
Peripheral Component Interconnect (PCI) bus also known as 
Mezzanine bus. 

[0025] Computing device 20 typically includes a variety 
of computer readable media. Computer readable media can 
be any available media that can be accessed by computing 
device 20 and includes both volatile and nonvolatile media, . 
removable and non-removable media. By way of example, 
and not limitation, computer readable media may comprise 
computer storage media and communication media. Com- 
puter storage media includes both volatile and nonvolatile, 
removable and non-removable media implemented in any 
method or technology for storage of information such as 
computer readable instructions, data structures, program 
modules or other data. Computer storage media includes, but 
is not limited to, RAM, ROM, EEPROM, flash memory or 
other memory technology, CD-ROM, digital versatile disks 
(DVD) or other optical disk storage, magnetic cassettes, 
magnetic tape, magnetic disk storage or other magnetic 
storage devices, or any other medium which can be used to 
store the desired information and which can be accessed by 
computing device 20. Communication media typically 



embodies computer readable instructions, data structures, 
program modules or other data in a modulated data signal 
such as a carrier wave or other transport mechanism and 
includes any information delivery media. The term "modu- 
lated data signal" means a signal that has one or more of its 
characteristics set or changed in such a manner as to encode 
information in the signal. By way of example, and not 
limitation, communication media includes wired media such 
as a wired network or direct-wired connection, and wireless 
media such as acoustic, RF, infrared and other wireless 
media. Combinations of the any of the above should also be 
included within the scope of computer readable media. 

[0026] The system memory 22 includes computer storage 
media in the form of volatile and/or nonvolatile memory 
such as ROM 24 and RAM 25. A BIOS 26, containing the 
basic routines that help to transfer information between 
elements within computing device 20, such as during start- 
up, is typically stored in ROM 24. RAM 25 typically 
contains data and/or program modules that are immediately 
accessible to and/or presently being operated on by process- 
ing unit 21. By way of example, and not limitation, FIG. 2 
illustrates operating system 35, application programs 36, 
other program modules 37, and information storage 38, 
which can include such items as a collection of images 43 or 
a collection of audio files 44. 

[0027] The computing device 20 may also include other 
removable/non-removable, volatile/nonvolatile computer 
storage media. By way of example only, FIG. 2 illustrates 
a hard disk drive 27 that reads from or writes to non- 
removable, nonvolatile magnetic media such as hard disk 
60, a magnetic disk drive 28 that reads from or writes to a 
removable, nonvolatile magnetic disk 29, and an optical disk 
drive 30 that reads from or writes to a removable, nonvola- 
tile optical disk 31 such as a CD ROM or other optical 
media. Other removable/non- re movable, volatile/nonvola- 
tile computer storage media that can be used in the exem- 
plary operating environment include, but are not limited to, 
magnetic tape cassettes, flash memory cards, digital versatile 
disks, digital video tape, solid state RAM, solid state ROM, 
and the like. The hard disk drive 27 is typically connected to 
the system bus 23 through a non- removable memory inter- 
face such as interface 32, and magnetic disk drive 28 and 
optical disk drive 30 are typically connected to the system 
bus 23 by a removable memory interface, such as magnetic 
disk drive interface 33 and optical disk drive interface 34. 

[0028] The drives and their associated computer storage 
media discussed above and illustrated in FIG. 2, provide 
storage of computer readable instructions, data structures, 
program modules and other data for the computing device 
20. In FIG. 2, for example, hard disk 60 is illustrated as 
storing operating system 35, application programs 36, other 
program modules 37, and information store 38. A user may 
enter commands and information into the computing device 
20 through input devices such as a keyboard 40 and pointing 
device 42, commonly referred to as a mouse, trackball or 
touch pad. Other input devices (not shown) may include a 
button, microphone, joystick, game pad, satellite dish, scan- 
ner, or the like. These and other input devices are often 
connected to the processing unit 21 through a user input 
interface 46 that is coupled to the system bus, but may be 
connected by other interface and bus structures, such as a 
parallel port, game port or a universal serial bus (USB). A 
monitor 47 or other type of video presentation appliance can 
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also connected to the system bus 23 via an interface, such as 
a video interface 48, and a computer speaker 56 or other type 
of audio presentation appliance can be connected to the 
system bus 23 via an interface, such as an audio interface 55. 
In addition to the monitor and speaker, computing devices 
may also include other peripheral output devices, such as 
printers, which are not shown. 

[0029] The computing device 20 may operate in a net- 
worked environment using logical connections to one or 
more remote computers. The logical connections depicted in 
FIG. 2 include a local area network (LAN) 51 and a wide 
area network (WAN) in the form of Internet 50, but may also 
include other networks, such as intranets, and are not meant 
to be limited to networks using TCP/IP communication. 
When used in a LAN networking environment, the comput- 
ing device 20 is connected to the LAN 51 through a network 
interface or adapter 53. The computing device 20 shown in 
FIG. 2 is networked, via LAN 51, to a broadband modem 
49, such as a cable modem, a Digital Subscriber Line (DSL) 
modem, satellite modem, or the like. A broadband modem 
49 connected to the LAN 51 allows multiple computing 
devices to share the same broadband connection, allowing 
more users faster access to WANs such as Internet 50. 
Alternatively, the computing device 20 can include a modem 
54 or other means for establishing communications over the 
WAN, such as the Internet 50. The modem 54, which may 
be internal or external, may be connected to the system bus 
23 via the serial port interface 46. In a networked environ- 
ment, program modules depicted relative to the computing 
device 20, or portions thereof, may be stored in the remote 
memory storage device. It will be appreciated that the 
network connections shown are exemplary and other means 
of establishing a communications link between the comput- 
ers may be used. 

[0030] In the description that follows, the invention will 
be described with reference to acts and symbolic represen- 
tations of operations that are performed by one or more 
computer, unless indicated otherwise. As such, it will be 
understood that such acts and operations, which are at times 
referred to as being computer-executed, include the manipu- 
lation by the processing unit of the computer of electrical 
signals representing data in a structured form. This manipu- 
lation transforms the data or maintains it at locations in the 
memory system of the computer, which reconfigures or 
otherwise alters the operation of the computer in a manner 
well understood by those skilled in the art. The data struc- 
tures where data is maintained are physical locations of the 
memory that have particular properties defined by the format 
of the data. However, while the invention is being described 
in the foregoing context, it is not meant to be limiting as 
those of skill in the art will appreciate that various of the acts 
and operation described hereinafter may also be imple- 
mented in hardware. 

[0031] Turning to FIG, 3, the operation of a Universal 
Plug and Play (UPnP) network 4 can be illustrated in the 
context of an average home 100, having a master bedroom 
102, a kitchen 104, a living room 106, an office 108, and a 
kids bedroom 110. The UPnP network 4 can be connected to 
appliances through various different ports. For example, 
computing device 20 can be connected to the UPnP network 
4 through the network interface 53 or the serial port interface 
46. One preferred embodiment uses network interface 53 to 
connect the computing device 20 to the UPnP network 4 



because the network interface 53 provides efficient through- 
put of data using the standard networking protocols relied on 
by the UPnP architecture, as explained below. Alternatively, 
the UPnP network 4 can also be connected to computing 
device 20 through the video interface 48 or the audio 
interface 55, for networking presentation appliances which 
can present video or audio data, respectively, The computing 
device 20 can maintain a connection to the Internet 50, 
through a broadband connection 112, and can share the 
connection 112 through the UPnP network 4. The broadband 
connection 112 can use a broadband modem 49, or other 
broadband connection hardware. Additional devices or con- 
trol points can be attached to the network 4, and can share 
the resources of the other devices or control points. 

[0032] As will be known by those of skill in the art, the 
UPnP Architecture, as expressed in The Universal Plug and 
Play Device Architecture Version 1.0, incorporated herein 
by reference in its entirety, defines UPnP compliant appti 
ances as either "devices" or "control points." A UPnP device 
advertises its abilities and is controlled by a control point, 
while a control point listens or searches for devices it is 
capable of controlling. The office 108 contains the comput- 
ing device 20, which often acts as a control point. The 
computing device 20 searches for, and listens to, devices on 
the UPnP network 4. An exemplary UPnP device can be a 
printer 116 attached to the network 4. When the printer 116 
is initially connected, it advertises its services, such as 
printing, form feeding, envelope feeding, and the like. The 
control point, in the form of computing device 20, listens for 
such advertisements, and when they are received, responds 
with a request for further information if the control point is p 
interested in the service advertised by the device. I 

[0033] The UPnP architecture relies on well known net- 
working protocols, such as the Transfer Control Protocol 
(TCP), the Internet Protocol (IP) and the HyperText Transfer 
Protocol (HTTP). Thus, when the printer 116 advertises its 
services, it sends a file through HTTP using a markup 
language. The extensible Markup Language (XML) can be 
used by the UPnP architecture to transmit information 
between devices and control points. The file sent by the 
printer 116 to advertise its services can be a page written in 
XML, specifying information about the printer, the services 
it provides, and the address of additional pages of informa- 
tion regarding each of the services advertised. In such a 
manner, the control point need only issue the well known 
HTTP "get" request on one of the pages specified by the 
printer 116 to obtain further information and learn how to 
control the printer. 

[0034] Table 1 below illustrates a sample XML page that 
could be sent by printer 116 to advertise its services. As will 
be known by those skilled in the art, XML classifies data 
contained within the document by using tags, which are 
identified by brackets. For example, a <device> tag indicates 
the beginning of a set of data about a device, and a </device> 
tag indicates the end of the set of data about the device. 
Because XML is extensible, new tags can be defined through 
an XML schema, as will be described further below. An 
XML document, such as that shown in Table 1, can reference 
an appropriate schema in order to provide a context and 
meaning for the tags used in the document. The first two 
lines of Table 1, for example, identify the version of XML 
used, and the schema document that provides the definitions 
of the tags used. 
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[0035] The "device" element in Table 1, identified and 
bounded by the <device> and </device> tags, contains the 
description of the printer 116 and can contain a number of 
sub -elements which provide the structure through which the 
printer can advertise itself and its services. For example, the 
"manufacturer" sub-element can provide the name of the 
manufacturer of the printer, the "modelName" sub-element 
can provide a model name the printer was assigned by its 
manufacturer, and the "modelNumber" sub -element can 
provide a model number which was assigned to the printer. 
The "device" element also contains the "serviceList" sub- 
element, which can list services offered by printer 116 
through further sub-element "service". Table 1 illustrates 
one "service" element used to provide information on the 
printing service. The "service" element, in turn, has sub- 
elements which can define a service identifier (the "servi- 
ced" sub -element), a Uniform Resource Locator (URL) of 
a page with more information about the service (the "SCP- 
DURL" sub-element), and a URL of a page which can be 
used to control the service (the "controlURL" sub-element). 
Additional services can be listed under the "serviceList" 
element through the use of more "service" sub-elements as 
shown in Table 1 below. 

TABLE 1 



[0037] FIG. 4 illustrates an exemplary set of communi- 
cations between a control point 150, in the form of com- 
puting device 20, and a device 152, in the form of printer 
116. Initially, as described above, the device 152 advertises 
its standard services in step 156 by sending an XML file such 
as the one shown in Table 1. If the control point 150 is 
interested in the services advertised, it can request a service 
information page at step 157, such as page "print.xml" 
identified in the device description page of Table 1. At step 
158, the device 152 can respond by sending the requested 
page, which can contain further information regarding the 
service 154, as described above. The control point 150 can 
then request an action in step 159 by sending an HTTP 
"post" message to the page for the service 154, such as the 
page "printcontroLxml" specified in Table 1, using the 
arguments and variables specified by the service information 
page returned at step 158. The device 152 will perform the 
action requested at step 159 and can change certain state 
variables as a result of the performance of the action. These 
state variables can then be communicated to the control 
point 150 in a response message 160, as indicators that the 
action was performed. Should the control point 150 require 



<?xml version="1.0"?> 

<root xmlns=**urn:schemas-upnp-org;device-]-0"> 
<spccVcrsion> 

<major>l </major> 

<mxnor>0</minor> 
</specVersion> 
<device> 

<dcviccTypt>um:schcmas-upnp-org:dcvLCc:printcr:l</dcviccTjT)C> 
<frie ndly Name >Printei</friendly Name > 
<manufacturer>PrinterCo</manu£acturer> 

manufacturer URL> http ://www.pr in terco.cc m</manufacturerUR L> 
<rnodelDescription>Ink Jet Printer</model Description 
<modelName>JetPrint</modelNamc> 
<modelNumber>100</modelNumber> 

<modelURL>http ^/www.p rinterco.com/jetprintl 00.htmWmodelURL> 
<seria]Number>123-4567890</serialNumber> 
<UDN>1 234:567</UDN> 
<UPC>JP100-1234<yUPC> 
<seiviceList> 
<service> 

<se rviceiypourn :schemas -upnp-org;service :prin t : 1 </serviceTyp e> 
<BerviceId>urn:upnp-org:serviceId:print</6erviceId> 
<SCPDURL>printJtmWSCPDURL> 
<controlU RL>printco ntro l.xml </co n trol URL> 

^service > 

<service> 

-- a second service can be described here -- 
</servicc> 
<^serviceList> 
<ydevice> 
</root> 



[0036] Returning to FIG. 3, if the control point, as imple- 
mented by computing device 20, needed further information 
regarding one of the services advertised by the printer 116, 
it can issue the HTTP "get" command on the file specified 
by the "SCPDURL" sub-element within the "service" ele- 
ment. Thus, per the example in Table 1, the control point can 
issue a "get" command on the file "print.xml" to obtain 
further information regarding the print service, including 
information on arguments to be passed, variable to be used, 
and the data type, range, and event characteristics of each. 
Armed with this information, the control point can formulate 
an appropriate command, such as a request to print a 
specified page on a specified paper type, using a specified 
quality of printing, and can send the request to the page 
specified in the <controlURL> tag. 



further information, it can query specific variables at step 
161 in the same manner as requesting an action to be 
performed (e.g. with an HTTP "post" message), and the 
values of the requested variable can be returned by the 
service 154 at step 162. 

[0038] As can be seen, the UPnP architecture allows 
devices and control points to establish communication with 
one another and allows control points to learn the functions 
offered by devices with no interaction on the part of the user. 
Returning to FIG. 3, the printer 116 need only have been 
plugged into the UPnP network 4 and the control point 150, 
implemented in computing device 20, would have been able 
to locate the printer 116 and use it. 
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[0039] In a similar manner, many types of devices can be 
connected to a UPnP network, such as network 4. For 
example, television sets, such as televisions 120, 128, and 
134 can act as UPnP devices in a manner similar to printer 
116. Similarly, electronic picture frames (EPFs) 124, 126, 
and 132, as well as stereos, such as stereo 122 or 130, can 
all act as UPnP devices. In a manner similar to printer 116, 
each of these devices will advertise their services by broad- 
casting an XML file, such as that shown in Table 1. Of 
course, the XML file of Table 1 references an XML schema 
for printers: "um:schemas-upnp-org:device:printer:r*. A 
different schema can be used for each of the other types of 
devices on network 4, shown in FIG. 3. For example, 
televisions 120, 128, and 134 can be described by an XML 
file referencing a television schema, such as "ura:schemas- 
upnp-org:device:television:l". Similarly, schemas "urn- 
:schemas-upnp-org:device:epf:l" and "urn:schemas-upnp- 
org: device :stereo:l" can exist for creating XML files 
describing EPFs 124, 126, and 132 and stereos 122 arid 130, 
respectively. 

[0040] As is known by those of skill in the art, a schema 
defines a class of XML documents. Each of the tags, or 
elements, in an XML document can be defined in the schema 
the XML document has referenced. Elements can be simple, 



in that they contain merely numbers or characters, or they 
can be complex and contain sub-elements, some of which 
may have further sub-elements still. Table 2 below contains 
an exemplary XML schema defining a class of XML docu- 
ments to which the exemplary device description document 
in Table 1 belongs. As can be seen from Table 2, elements 
are defined in terms of sub -elements, or of simple data types. 
Thus, the element "root" (identified by the <root> tag in 
Table 1 above) contains an element named "specVersion" 
and an element named "device." Referring back to Table 1, 
it can be seen that the root element contains only the two sub 
elements enumerated in the schema in Table 2: the "spec- 
Version" element and the "device" element. Each of the 
elements "specVersion" and "device" is also defined in the 
schema. The element "specVersion" contains two sub-ele- 
ments: "major" and "minor", each of which are further 
defined as being of type "int" or integers. Because the 
sub-elements "major** and "minor*' are simple types, no 
further levels of definition are necessary, and the element 
"specVersion" is fully defined. The "device" element is 
similarly defined, having sub-elements, some of which, like 
"deviceType" and "manufacturer" are simple elements, and 
others, like "service" are complex and defined by still further 
sub-elements that are simple. 



TABLE 2 



<?xml version="1.0"?> 
<Schema name="device-l-0" 

xmlcts="urn3chcmas-niicr05oft-com:xni]-data M 

xml ns : dt~"ura rschemas -microsoft-co m :data type"> 
<EIementType name-"root" content-"eltOnly"> 

<element type»" specVersion" /> 

<element type«'*device" > 
</ElcmcntTypc> 

<EtementType name="spec Version" content="eltOnly"> 

<element type-" major" /> 

<element type«"minor" /> 
</ElementType> 

<ElemcntTypc name="major" dt:type="int" contcnt="tcxtOnly" /> 
<ElernentType name="minor" dt:type='*int" content="textOnly" /> 
<ElementType name-"device" content- u eltOnly"> 

<elemenl type="deviceType" /> 

<element type-"friendlyName" /> 

<elcincnt typc=" manufacturer" /> 

<element type="manufacturerURL" minOccurs="0" maxOccurso w l" /> 
<element type-"modelDescription" minOccurs-"0" maxOccurs-"!" /> 
<element type»"modelName*7> 

<eJement type- w modelNumber" minOccurs-"0" maxOccurs-" 1" /> 
<elcmcnt type»"modclURL" rninOccurs="Q" maxOccurso*!" I> 
<element type="serialNumber" minOccurs="0" maxOccursa"l" /> 
<element type-"UDN" /> 

<element type="UPC" minOccuiWO" maxOccurs="l" > 
<elemeat type-"servicelist" )> 
</ElcmentType> 

<ElementType name="deviceType" dt:type="uri" content="textOnly" /> 
<ElementType name-"friendlyName"dt:type-"string" content-"tcxtOnly" /> 
<ElementType name="manufacturer" dt:type="string" content="textOnly" /> 
<ElementType name-"manufacturerURL" dt:type-'^iri" content-"textOnly" /> 
<ElementType name="modelDescription" dt:type= w string" content"* tcxtOnly" /> 
<ElementType name="modelName" dt:type="string" content="textOnly" /> 
<ElementType name-"modelNumber" dt:type« w string" contcnt-^tcxtOnly" /> 
<ElemenlType name»"modelURL" dt:type="uri" content="tfixtOnly" /> 
<ElementType name-"seriai Number" dt:type-"string" content-" textOnly" /> 
<ElementType name»"UDN" dt:type-"uri" content^tcxtOnly" /> 
<ElementType name="UPC" dt:type»"string" contenU«"textOnly" /> 
<ElemcntTypc namc-"sc^viccUst* , content-"cltOnly"> 

<elemenl type-"service" minOccurs-'T* maxOccurs«""" /> 
</ElementType> 

<ElcmentType namc-"scrvicc" content-"eltOnly"> 
<element type-"serviceType" /> 
<element type="serviceld" /> 
<e1emem type-"SCPDURL" /> 
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TABLE 2-continued 



<element type=" control URL" > 
<clcmcnt type="evcntSubURL" /> 
</ElementType> 

<ElementType name-"serviceType" dtitype-^uri" content-" textOnly" /> 
<ElcmenrType name="serviceld" dt:type«"uri" conrent="textOnly" /> 
<ElementType name="SCPDURL" dt:typeo"uri" content*»"textOnly" /> 
<ElcmcntTypc namc="controlURL" dt:type«»*uri" content="textOnly" /> 
<ElementType name="eventSubURL" dt:lype="uri*' content-" textOnly" /> 
VSchema> 



[0041] Because a schema defines a class of documents, it 
is not required that every document within that class contain 
all of the elements defined in the schema. However, a 
document of the class defined by a schema may not contain 
elements that are not defined within the schema. Further- 
more, the UPnP architecture implements the Flexible XML 
Processing Profile (FXPP), which specifies that devices and 
control points can ignore elements, and all sub-elements, 
which are not understood by the device. Thus, a more 
complex schema can be defined, allowing those devices and 
control points having appropriate capability access to addi- 
tional features, while maintaining compatibility with older 
or less advanced devices and control points. The older or less 
advanced devices would simply advertise with an XML page 
that did not use all of the elements contained within the 
schema defined for that class. Similarly, older or less 
advanced control points would simply ignore those XML 
elements that they did not understand. 

[0042] In accordance with one important aspect of the 
invention, an extended XML schema is provided for 
enabling devices and control points to allow a user of a 
device access to multiple categories of information, allow- 
ing the user to tune the information presented through the 
device. The XML schema for UPnP devices can define 
additional elements, as will be explained in more detail 
below, that can be used by devices and control points to 
define and present categories of information to a user. The 
additional elements, however, will not interfere with the 
normal operation of a UPnP network, as the additional 
elements within the device description document will be 
ignored by control points that do not contain the capabilities 
of the present invention. Because the information capable of 
being presented can come in various forms and formats, 
additional XMLschemas are contemplated for various types 
of information presentation appliances. 

[0043] In accordance with another important aspect of the 
invention, information presentation appliances which tradi- 
tionally behaved as devices within the UPnP architecture can 
act as control points, allowing the information presentation 
appliance greater flexibility in presenting categories of infor- 
mation to a user and allowing the user to tune the informa- 
tion presented through the appliance acting as a control 



point. An information presentation appliance, such as an 
EPF, a stereo, or a printer, is generally a device under the 
UPnP architecture because it is controlled by a control point 
that feeds, or pushes, to the information presentation appli- 
ance, the information that the appliance is to present, includ- 
ing images, sound, or hard copy output. The present inven- 
tion contemplates the information presentation appliance as 
a control point within the UPnP architecture, enabling it to 
request information from information storage appliances 
and servers, which, in turn, would be devices within the 
UPnP architecture. In this manner the information is pulled, 
or fetched, by the information presentation appliance, rather 
than being pushed to it. 

[0044] In accordance with a further important aspect of the 
invention, an information presentation appliance within a 
UPnP network contains hardware and software for present- 
ing categories of information to a user to allow the user to 
tune the appliance. A user interface is contemplated, imple- 
mented through various user input devices, which can 
enable a user to select among available categories of infor- 
mation to be presented to the user by each information 
presentation appliance. 

[0045] In keeping with the invention, Table 3 illustrates an 
exemplary extended XML schema contemplated by the 
present invention. For clarity, the additional elements in 
Table 3, not found in Table 2, are shown in bold type. For 
example, the present invention contemplates an additional 
element, such as that named "informationCategoryList" in 
Table 3, which allows compliant devices to describe the 
types of information content they can present. As will be 
described further below, the user can be presented with a 
general listing of categories of information, such as styles of 
music, or genres of images, or categories of video clips, 
which the user can choose to be presented by the particular 
device. The user's selection can then be stored in the device 
and presented as part of the device information page using 
the schema of Table 3. The "informationCategoryList" ele- 
ment can contain sub -elements to further specify the user's 
selections. In such a manner, the exact title of the category 
of information selected by the user does not need to be 
matched, since additional information, such as keywords, 
can be used to more accurately present the user's selections. 



TABLE 3 



<?xml vers ion ="1.0"?> 
<Schccna nemc5-"dcvicc-l-0" 

xm lns»**urn :schemas- microsoft-com :x ml -data" 

xmlns:dt-"urn:schcmas-microsoft-com:datatypcs"> 
<ElementType name-" root" content-"eltOnly"> 

<element type="spec Vers ion" /> 

<clcmcnt typc- M dcvice" /> 
</E[ementType> 
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TABLE 3-continued 



<ElementType name="specVersioQ" contentV*eItOnly"> 

<cicmcnt typc=" major" /> 

<element type«»" minor" /> 
</ElementType> 

<ElementTVpe name="major" dt:type="int" content-" textOnly" /> 
<ElementType name="minor" dt:type="int" content="textOnly" /> 
<ElcmcntTypc namc="dcvicc" contcnt»"cltOnly"> 

<element type="deviceType" /> 

<element type- friendlyNa rue" /> 

<element type=" manufacturer" /> 

<element type=" manufacturer URL" minOccurs="0" maxOccurs="l" /> 
<clement type="modelDcscription" minOccurs="0" maxOccurs="l" /> 
element type="modelName" /> 

<ele merit type-"mode]Number" minOccurs-"(T maxOccurs-"17> 
<element type="modelURL" minOccurs="0" maxOcoirs="l" /> 
<element type-^serialNumber" minOccurs-"0" maxOccurs-'T' /> 
<element type="UDN" /> 

^element type-** UPC* minOccurs="0" maxOccurs= M l" /> 
<element type-"serviceList" /> 
<element type="informationCategoryList" /> 
</ElementType> 

<ElementType namc»"deviceTypc" dt:typc="uri" contents" textOaly" /> 
<ElementType name»"friendlyName"dt:type= M string" contents "16X10111/* /> 
<ElementType name-"manufacturer" dt:typc- w 3tring" content-"textOnly" /> 
<ElemenfI\pe name«"manufacturerURL" dt:type="uri" content="textOnly" /> 
<ElementType name-"modelDescription" dt:type-**string" content»"textOnly" /> 
<ElcmentType name='*inodelName" dt:typc="string" content"" textOnly" /> 
<ElementType name^modelNumber" dt:type="string" content»"textOnly" /> 
<EtementType name-*modelURL" dt:type-"uri" content- M textOnly" /> 
<ElementType name="serialNumber" dt:type»"string" content="textOnly" /> 
<ElementType name-"UDN" dt:type-"uri" content="textOnty" /> 
<ElementType name="UPC dt:type="string" content*»"tcxtOnly" /> 
<ElementType name="serviceList" content*^ ItOnly" /> 

<element type-"service" minOccura-'T' rmxOccurs-*'*" /> 
</ElementType> 

<ElementType name-"service" convent-"eltOnly"> 

<elcmcnt typc="scrviccTypc" /> 

<element type«"serviceld" /> 

<element type-"SCPDURL" /> 

<element type»"controIURL" /> 

<element type-"eventSubURL" f> 
</ElementlType> 

<ElementType name="serviceType" dt:type="uri" content=**textOnly" /> 
<ElementType name="serviceld" dt:typc="uri" content="textOnly" /> 
<ElementType name="SCPDURL" dt:type=urf* content="textOnly" /> 
<ElementType name-"controlURL" dtitype-^uri" content-"textOnly" /> 
<Elemcntlype name="eventSubURL" dt:typc="uri" content^'textOnly"^ 
<ElementType name="informationCategoryList" contents" eltOnly" /> 

<clcmcnt typc="mfo rmationCategory" rninOccurs="l" maxOccurs-"*'7> 
</ElementTypc> 

<ElementType name-"InformationCategory" content-" eltOnly" > 

<element type="InformationCategoryName" /> 

<element type=" Information^ te gory KeyworUst" /> 

<element type-" InformationCategoryBlockedKeyword List" /> 
</ElementType> 

<ElementType name-'InformationCategoryName" dtitype-'W content-" textOnly" /> 
<ElcmcntTypc namc« w inforrnationCatcgoryKeywordList" content="eltOnly"> 

^element type««*'informationCategoryKeyword'* minOccurs="0" maxOccurs=*'"" /> 
</ElcmcntTypc> 

<ElemenfType name«"informationCategoryBlockedKeywordUst" content^eltOnly'^ 

<element type-"informationCategoryBlockedKeyword" minOccure~"0 " maxOccure-"*" /> 
<ElcmenfType name-" Info rmationCategory Keyword" dt:type="uri" content**" tcxtOnly" !> 
<ElementType name**" Info rmationCategory BlockedKeyword" dt:type«**uri" contenU"textOnly" /> 
<?/Schcma> 



[0046] As shown in Table 3, the "informationCategoryL- 
ist" is an element that lists one or more "information Cat- 
egory" elements, allowing the user the opportunity to select 
multiple categories of information to be presented on the 
device. For each "informationCategory" element, sub-ele- 
ments "InformationCategoryName M , " InformationCatego- 
ry KeywordList" and "InformationCategoryBlocked- 
KeywordList" allow the device to specify, respectively, 



within the device description page: a common name for the 
information category, keywords which can help identify the 
information category selected if there is no exact match to 
the information category name on the control point, and 
blocked keywords, which can be used to identify types of 
categories which are not to be presented by the device. To 
allow the user to list keywords, elements "Information Cat- 
egory KeywordList'* and " Information CategoryBlocked- 
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KeywordList" are implemented as lists, having a single 
sub-element "InformationCategoryKeyword" and "Informa- 
UonCategoryBlockedKeyword", respectively. The "Infor- 
mationCategoryKeywordList" and "InformationCategory- 
BlockedKeywordList" elements can contain no elements, 
allowing the user not to specify keywords if they so choose. 

[0047] Returning to FIG. 3, an EPF 124 is shown in the 
living room 106. The EPF 124 can present to the user an 
interface to allow the user to select the image or video clip 
categories to be presented on the EPF 124. As will be 
described further below, the user can be presented with a 
generic list of categories of images to be displayed, and an 
opportunity to enter keywords to further define the catego- 
ries. Thus, for display in the living room, the user might 
select a "family" category and a "friends" category, and can 
enter further keywords, such as the names of the family 
members, or the locations that the family went on vacation 
to further define the category of images. The user can also 
be allowed to enter keywords of images the user does not 
wish to be displayed in the living room, such as advertise- 
ments, coupons, or delivery room pictures of the user's 
children. Once the user has made these selections, the EPF 
124 can create a device description page such as the one 
show in Table 4, below. 

[0048] Using an extended schema contemplated by the 
present invention, such as the one illustrated in Table 3 
above, the device description in Table 4 can contain infor- 



mation regarding the types of images the user wishes to have 
displayed on the EPF 124 in the living room 106. For 
purposes of illustration, the elements of the device descrip- 
tion in Table 4 which take advantage of the extended schema 
of Table 3, are shown in bold type. As can be seen, the 
element "informationCategoryList" provides a listing of the 
categories of images the EPF 124, acting as a device, is 
capable of displaying. The categories are each defined by the 
"informationCategory" elements, which, in the exemplary 
device description provided in Table 4, include the catego- 
ries named "family", "friends", and "blocked." Each of these 
categories contains sub-elements which allow for key 
words. Thus, the "family" category contains a sub-element 
"informationCategoryKeywordList", which, in turn, con- 
tains further sub-elements storing key words to further 
describe the "family" category. In this manner, if the control 
point sending the images to the EPF 124 does not have a 
"family" category, it may still be able to identify certain 
pictures to be sent to the EPF based on the key words 
provided. Similarly, the "family" category also contains a 
sub-element " info rmationCategoryBlockedKe ywo rdList" 
which contains keywords of images that should not be sent 
to the EPF. For example, the device description of Table 4 
provides that images described by the keyword "delivery 
room" should not be send to the EPF 124 in the living room 
106, even if such images are properly within the "family" 
image collection on the control point. 

TABLE 4 



<?xml vcrsion-"1.0"?> 

<root xmlns="u ra :sche mas-upnp- o rg:device- 1 -0" > 
<specVersion> 

<majo r> 1 </majon> 

<mi qo r>0 </m Lno r> 
</specVersion> 
<device> 

<deviceType>urn:schemas-upnp-org:device:epf: 1 </deviceType> 
<&icndlyNamoElcctronic Picture Frame -c/friendlyNa mo 
<manu£actu re r>EpfCo</manu facturer> 

<manufactu re rURL>http://www.epfco .com </manufacturcrURL> 
<modelDescription>LCD Picture Frame </modelDescription> 
<model Name >DigiFrame </modelName> 
<modclNumber>2</modclNumber> 

<model URL> http ://www. epfco.oom/digif rame2.html </mode 1URL> 
<seria 1 Number>987- 65 3210 </sc ria lNumber> 
<UDN>9S76:543</UDN> 
<UPC>DF2-9S76VUPC> 
<serviceList> 
<service> 

<serviceTVpe>urn:schcma3-upnp-org:scrvice:cpf:lVservicc1Vpc> 

<serviceld >urn :upnp-org:serviceId :epf </serviceId > 

<SCPDURL>display.xml</SCPDURL> 

<controlURLxlisplaycorjtrol.xinl</controlURL> 
</service> 
<service> 

—a second service can be described here - 
■^/servico 
</servicelist> 
<informationCategoryList> 
<infonnationCategory> 

<informationCategoryName>faim - ly<AnfonnatioriCotegoryName> 
<informationCategoryKeywordList> 

<info rma tionCategoryKe ywo rd>Mom</in forma lionCatego ry Keyword > 
<inf o nnationCategory Ke yword>Dad </informa tionCategory Keywo rd > 
<rinfo rmationCatcgory Kc ywo rd>M Dte</informa tionCatcgorvKe yword> 
<info rmationCategory Keywo rd>Am yVinformationCa lego ry Keyword > 
<i nformalionCategory Keywo rd List> 
<informationCategory Blocked KeywordList> 
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TABLE 4-continued 



<informationCategoryBlockedKcyword>De livery Room 
VinformationCatcgoryBlockcdKcyword> 
</infor ma tionCategory B lockedKeywo rdlist> 
</in for matio nCatego ry> 
</in for matio nCatego ry> 

<informationCalegoryName>friends </informationCategoryName> 
<info rmatio nCa tcgor y Key wordList> 

<informationCalegoryKeyword>Sarah</mformationCategoryKeyword> 
<inf ormat ionCategoryKeyword>Julie</infonnatio nCatego ry Keywo rd> 
<informatioriCategoryKeyword>Doug</informationCategoryKeyword> 
<inf or mat ionCate gory Keyword>Sue</uiformatiori Category Keyword > 
</infonnatLO nCatego ryKeywordLis t> 
•c/informatto nCatego ry> 

<informationCategoryName>blocked <^informationCategoryName> 
<info rmationCategoryB lockedKe ywordList> 

<informationCategoryBlockedKeyword>Coupon 
^informationCategory BlockedKcy Word > 
<inforrnationCategoryBlockedKeyword>AdvertLsement 
</informationCategoryBlockedKeyword> 
</informationCategoryBlockedKeywordList> 
</infor matio nCatego ry > 
<ViaformationCategoyList> 
</device> 
</root> 



[0049] The present invention contemplates that the infor- 
mation categories can be used, not only to enumerate those 
categories which the user wishes to have displayed on the 
device, but also to enumerate those categories which should 
not be sent to the device. The illustrative device description 
document shown in Table 4 contains an information cat- 
egory named "blocked" that contains no keywords, but does 
contain blocked keywords. Images matching the blocked 
keywords will not be displayed on the device even if they 
otherwise meet a selected category. Because, as shown in 
Table 3, the schema does not require a single entry in the 
"inform ationCategory Key wo rdList", it is possible that an 
information category exists which contains no keywords. 
Similarly, because the schema of Table 3 does not require a 
single entry in the "informationCategoryBlocked- 
KeywordList", it is possible that an information category 
exists which contains no blocked keywords, such as the 
category "friends" shown in Table 4. 

[0050] Turning to FIG. 5, an exemplary set of communi- 
cations is shown using the schema extensions contemplated 
by the present invention. The control point 180 can be the 
computing device 20. The computing device 20 can contain 
the images to be displayed in an image store 43, which can 
be located on a local storage medium, such as hard disk 60, 
or downloaded from a remote computing device, such as 
through the Internet 50. The images may be categorized into 
different folders or databases, or they may have keywords 
associated with them, such as can be done with a digital 
photo album. The EPF 124, acting as device 182, can 
broadcast, at step 186, its device description containing, in 
a manner similar to that described in Table 4, the user's 
preferences regarding the nature of the images to be dis- 
played. Upon receipt of the device description page, the 
control point 180 can compare the categories and keywords 
listed by the device 182 with the images contained within the 
image store 43 to determine whether it is appropriate to 
request the device to display any images. 



[0051] If the control point 180 cannot identify any images 
within the image store 43 that correspond to the categories 
or keywords provided in the device description received at 
step 186, then the control point 180 will not perform a 
request for additional services at step 189 and there will be 
no further communication between the control point and the 
device 182. However, if the control point 180 can identify 
images within the image store 43 that match the categories 
or keywords provided in the device description, it can 
request a service information page at step 187 to determine 
how to display the identified images on the device 182. As 
shown in FIG. 5, the device 182 contains at least one service 
184, whose functionality is described in a service descrip- 
tion page. The device description page of Table 4 enumer- 
ates a service information page called "displaycontrol.xml", 
which can be requested at step 187. In response to this 
request, the device can return the "displaycontrolxmr ser- 
vice information page at step 188. An exemplary "display- 
control.xml" service information page is shown in Table 5 
below. As can be seen, the exemplary service information 
page of Table 5 defines two actions: "GetDisplaylnfo" and 
"Putlmage". As will be explained further below, a control 
point can use a URL, by issuing an HTTP "get" command, 
to obtain information from a device or request that a device 
perform an action. Thus, as shown in FIG. 5, at step 189, the 
computing device 20 can use the "GetDisplaylnfo" action to 
request information from the EPF 124. At step 190, the EPF 
124 can return the information requested. The "GetDisplay- 
lnfo" action defined in Table 5, below, contains a number of 
defined variables, including: the width of the display of the 
EPF124, the height of the display of the EPF, and the color 
depth display capabilities of the EPF Given this informa- 
tion, the computing device 20 can scale an appropriate 
image to fit the display capabilities of the EPF 124, and can 
request the EPF 124 to display the image at step 191. A 
confirmation can then be returned at step 192, if necessary. 
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TABLE 5 



e?xml version="1.0"7> 

<scpd xmlns^urn: schcmas-upnp-orgscrvtcc-l-0"> 
<specVersion> 

<major>l </major> 
<miaor>0</minor> 
</specVersion> 
<serviceStateTable> 

estate Variable sendEvents» M yes"> 

ena me >CUrre n tlmageURLe/name > 
<da taType >uri</dataType > 
e/stateVariable> 

<statc Variable sendEvents="yes"> 
ename>lmageTitle</name> 
edataType>stringe/dataType> 
eystateV&riablo 

<state Variable sendEvents-"yes"> 

<namc>ImageAuthor</name> 

<dataType>stringe/dataType> 
e/stateVfcriable> 

estate Variable sendEvents="yes"> 

<name>IraageSubjectVname> 

edataType >string</dataType> 
e/stateVariable> 

<state Variable send Events-" yes"> 

-<name>ImageI^teTirneTaken</name> 
edataType >stringe/dataType> 
e/statcVariable> 

<state Variable sendEvents="no"> 

ename>ImageGpsLatitudee/aame> 

edataType>stringe/dataType> 
Estate Variable > 

estate Variable sendEvents-^no'^ 

<name>ImageGpsLongitude</oame> 

edataType >stringe/dataType> 
</stateVariable> 

estate Variable BendEvents-"no"> 

enamolmage Actual Width </name> 

edataType >ui4 e/dataType > 
</stateVariabIe> 

estate Variable send Events^ no"> 

ename>ImageActualHeighte/name> 

edataType >ui4 e/dataTypc > 
e/stateVariable> 

estate Variable scndEvcnts="no"> 

ename>ImageActualColorDepthe/name> 

edataType >ui4 </dataType 
e/stateVariabIe> 

estate Variable sendEvents="no'*> 

enamoD Lspl ay Width </na me> 

edataType >ui4</dataType> 
</stateVferiable> 

estate Variable sendEvents^no'^ 

<na me>D ispl ay Height </na me > 

edataType >ui4 e/dataType > 
e/state\&riable> 

estate Variable sendEvents-"no"> 

ena me >D ispl ayCo lorDcpth </na me> 
edataType>ui4 e/dataType > 
e/state Variable > 
</serv iceStateTabl e > 
<actionList> 
eaction> 

ename>GetDisplay[nfoeyname> 
eargumentlist> 
<argument> 

ename>Widthe/name> 

erelatedStateVariable>DisplayWidthe/relatedStateV^riable> 

ed irectio n >out e/dir ectio n> 
e/argument> 
eargument> 

ena me > Height </name> 

erelatedState Variabl oDisplay He ight<7relatedS tateMi riab le> 

edirectio n >oute/direction> 
e/argument 
eargument> 

ename>ColorDepthe/name> 
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TABLE 5 -continued 



<relatedStateVariable>DisplayColorDepth</relatedStateVariable> 
<dircctio n >out<c/directio n> 
</argumem> 
</argumentList> 
</action> 
<action> 

cnamoPut Im agc<^namc> 
<argumentUst> 
<argument> 

<name>[mageURL</name> 

<reIatedStateVariableCurrentImageURL^/related Slate Variablo 

<dircct;o n >tn^/d ircction > 
</argument> 
<argument> 

<name>[mageTitle</oame> 

<relatedStateVariab]e>ImageTitle<7relatedState\^riable> 

<d ircctio n >in</dircction > 
</aigument> 
<argument> 

<name>ImageAuthor</name> 

<relatedStateVariable> Image Author </relatedStateVariabIe> 

<d irectio n > in</direction > 
</aigument> 
<argument> 

<name>ImageSubject</name> 

<re latedStateVa riabl e> ImageSubject</re la ted State Variable > 

<dircction>in</direction> 
</argument> 
<argument> 

<name >I mageDateHme'Rike </na me> 

<reLatedState VariabIe>ImageDateTiineTake n </relatedState Variable > 

<dircctio n >in ^direction > 
</argument> 
<argument> 

<name>[mageGpsLatitude</name> 

<relatedStateVariabIe>ImageGpsLatitude</relatedStateVariable> 

<direction>in</direction> 
</argument> 
<argument> 

<name>I ma geGps Longitude </name> 

<re la tedStateVa riabl e> Ima geGps Longitude </re latedState Variablo 

<direction>iu</direction> 
</aigument> 
<nrgument> 

<name>ImageActualWidth</name> 

<re la tedStateVa riabl e> Image Actua IWid th</re Iated State Variab le> 

<d irectio n>in</direction> 
</argument> 
<argument> 

<name>ImageActualHeight</name> 

<relatedState Variablo Image ActualHeight<relatedStateVariable> 

<d ircction > in</direction > 
</argument> 
<argumcnt> 

<name >I mage AcrualColo rDepth <J oa me> 

<retatedStateVariable> Ima geActualColorDepth</relatedS tate \&riable > 
<d irectio n >in </direction> 
</argument> 
</argumcntList> 
</action> 
VactionList> 
</scpd> 



[0052] The "Putlmage" action defined in the exemplary 
service description page of Table 5 above, contains both the 
location of the image and arguments for passing image 
"metadata" — data about the image. The "ImageURL" vari- 
able can contain the location of the scaled image, which the 
EPF 124 is to display. The arguments, however, can contain 
further information, which the user can select the EPF 124 
to display together with the image. For example "Imag- 
eTitle", "I mage Author", and "ImageSubject" can contain 



information about the title, author, and subject of the image 
taken, and can be edited by the user. Additional variables can 
contain data imprinted by a digital camera. For example, 
"ImageDateTimeTake", " "ImageGPSLatkude", 

"ImageGPSLongitude", "I mage Actual Width", " Image Actu- 
alHeight", and "I mage Acutal Color Depth" can contain a 
date/time stamp, a location stamp, and image data as 
recorded by the digital camera or other digital image capture 
device. 
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[0053] As an alternative to the modifications to the schema 
of a UPnP device disclosed above, the present invention also 
contemplates an information presentation appliance, which 
traditionally would act as a device under the UPnP archi- 
tecture, acting as a control point. For example, EPF 124 can 
become a UPnP control point on the UPnP network 4. With 
the information presentation appliance, such as EPF 124, as 
the control point, an image store, such as image store 43 in 
computing device 20 would become a device, The control 
point would search the UPnP network 4 for devices which 
contained information, or would wait for devices to adver- 
tise themselves, and would request that the device send the 
information to the control point to be presented to the user. 
As can be seen, by using an information presentation appli- 
ance as a UPnP control point, the presentation of information 
is changed from a "push" model, in which the information 
store pushes information to an information presentation 
appliance, into a "pull" model in which the appliance finds 
appropriate information stores and pulls the information 
from those stores that have the information it seeks. 

[0054] Table 6 below contains an exemplary device 
description such as might be used by the computing device 
20 to advertise its collection of images 43. As will be 
obvious to those skilled in the art, an analogous device 
description can be used for the collection of audio files 44, 
or any other information that can be presented to the user. As 
will also be known by those skilled in the art, a complex 
appliance, such as computing device 20 can act as more than 
one UPnP device. Thus, the computing device 20 can 
simultaneously act as a picture server device, serving images 
from the image store 43 and a audio server device, serving 
streaming audio from the audio store 44. 

TABLE 6 



[0055] As can be seen from Table 6, the "Picture Sharer" 
device exposed by the computing device 20 does not need to 
use the exemplary extended schema of Table 3, and can use 
a standard UPnP device schema, such as that shown in Table 
2. The "Picture Sharer" device of the description illustrated 
in the Table 6 above exposes a service "PictureStoreAccess" 
which allows a control point to request specific categories of 
images to be displayed. Table 7, below, contains an exem- 
plary service description page of the "PictureStoreAccess" 
service. The exemplary service description page of Table 7 
allows the control point, implemented as the EPF 124, to 
request the categories of pictures, or "albums", available on 
the "Picture Sharer" device and to request information about 
each of the albums, including a name of the album, a 
preview of the album, a default play direction for the images 
in the album, a default play mode for the album, the number 
of pictures in the album, and a URL for accessing a picture 
in the album. 

[0056] As can be seen, the exemplary service description 
page of Table 7 provides for four actions which can be 
invoked by the control point: "GetNumberOfAlbums", 
"GetAlbumldList", "GetAlbumlnfo", and "GetPicturelnfo". 
The "GetNumberOfAlbums" action can contain a single 
argument, "NumAlbums", which is returned by the "Picture 
Sharer" device and contains the number of image albums the 
device can send to the EPF 124. If "NumAlbums" is equal 
to zero, then the EPF 124 can indicate to the user that there 
are no published albums on the "Picture Sharer" device. The 
"GetAlbumldList" action likewise can contain a single 
argument, "AlbumldList", which is returned by the "Picture 
Sharer" device and contains a comma delimited list of 
identifiers of image albums the device can send to the EPF 



<?xml version-" 1.0"?> 

<root xmljis»"urn:schemas-upnp-org:dcvice-l-0"> 
<specVersion> 

<major>l </major> 

<ininor >0 </minor> 
</spec Vers ion 
<dcvicc> 

<deviceiype>um :schemas-upnp-org:devLce :PictureSharer:l </devtceType> 
<fricnd]yName>%s Picture Sharer</friendlyNamc> 
<manufacturer >Microsoft </manufactur er> 

■cmanufacturer URL>http ^/www.microso ftco m</manufactur er URL> 
<madelDcscription>Microsoft. Net Picture Sharer </modelDescription> 
<modelName>Microsofl .Net Picture Sharer </modelName> 
<modelNumbcr>1.0 <^modelNumber> 

<modelURL>htfp'y/w\^.priiiterco.conVmodelURL</modelURL> 
<serial Number> 1 </serial Number> 
<UDN>UdnFilled[nBvDeviceHostAPI</UDN> 
<U?C>1</V?C> 
<scrviccList> 
<service> 

<serviceType>u m :sche mas -upnp-o rg:se rvice : Pictu reS tor e Access : 1 </serviceType> 

<scrviccId>>urn:upnp-org:sendccId:PicturcStoreAcccss</serviceId> 

cSCPDURL>PicutreSharerService.xm]</SCPDURL> 

<controlURL><VcontrolURL> 

<c ventSubU RL></eve ntSub URL> 
</service> 
<se rvice > 

_ — a second service can be described here -- 

</service> 
</serviceList> 
</device> 
</root> 
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124. The "GetAlbumlnfo" action can contain a number of 
arguments for passing information from the "Picture Sharer" 
device. The "Albumld" argument can be sent as part of the 
"GetAlbumlnfo" action to the "Picture Sharer" device to 
identify the album from which the picture can be retrieved. 
The "GetAlbumlnfo" action can then return the arguments: 
"FriendlyName", which can be a name given to the album 
by the user or the album's creator, "NumPictures", which 
can contain the number of images in the album, "BasePic- 
tureURL", which is a URL that can be used by the control 
point to request an image through an HTTP "get" command, 
"BaseFileURL", which is a URL that can be used by the 
control point to request an non-image file through an HTTP 
"get" command, "PreviewURL", which is a URL that can be 
used by the control point to request a preview of the images 
in a specified album, "PlayDirection", which can contain the 
direction of the display of the images through the album, 
"PlayMode", which can contain the mode in which the 
images are displayed, and "DisplayTimeSeconds", which 
can contain the number of seconds to display each received 
image. The "GetPicturelnfo" action can also contain a 
number of arguments for passing information from the 
"Picture Sharer" device. As with "GetAlbumlnfo", "GetPic- 
turelnfo" provides arguments for identifying the picture 
about which further information is required, namely: " Albu- 
mlD" and "Picture Number", which can be passed to the 
"Picture Sharer" device and can contain, respectively, an 
identification of the album in which the picture is located, 
and the number of the picture within that album. The 
"Picture Sharer" device can then return the following argu- 
ments: "ActualPictureWidth", "ActualPictureHeight", 
"ActualPictureColorDepth", "PicutreFileName", "Picture- 
TakenTime", "PictureTitle", "Picture Author", "PictureSub- 
ject", and "DisplayTimeSeconds", which can contain, 
respectively, the width of the image, the height of the image, 
the color depth of the image, user given name of the image 
file, the date imprinted on the image, such as by a digital 
camera, the title given to the picture, the person who took the 
picture, the subject of the picture, and the length for which 
the picture should be displayed. The "GetPicturelnfo" action 
also provides an argument "PictureURL", which can contain 
the full URL for the picture file on the "Picture Sharer" 
device. 

TABLE 7 

<?xml version= H 1.0"? > 

<scpd xmlns-"ura:schemas-ijpnp-org:service-l-0"> 
<spccVersion> 

<inajor>l </major> 
<minor>0e/minor> 
</specVersion> 
eserviceStateTablo 

estate Va liable sendEvents="yes"> 
<name>NumAlbums</name> 
<dataTypc>i4VdataTypc> 
e/staleVariablo 

-estate Variable sendEvents-"yes"> 

<na mo Albu m Id List </namc> 

edataType >string</dataType> 
■c/statcVariablo 

estate Variable sendEvents-"yes"> ~ 

<name>LastChangedAlbum</name> 

edataType >stringe/dataType> 
e/stateVariablo 

estate Variable sendEvents- u no"> 

enamoA ARG TYPE Slringe/namo 
<da taType >string</dataTvpe > 



TABLE 7-continued 



Estate Variable > 

<state Variable sendEvents=>"no"> 

<name>A ARG TYPE URle/namo 

<dataType >uri </dataType> 
</state Variable > 

<state Variable sendEventsa M no"> 

<namc>A ARG TYPE Int</name> 

<dataType > i4</dataType> 
</fitate Variable > 

estate Variable sendEvents="no"> 

<name>A ARG TYPE PlayDirectioae/name> 
<dataType >stringe/dataTypo 
<al lowed Value List> 

<allowedValue>FORWARD</allowedValue> 
<allowedValue>BAGKWARD</allowedValue> 
<allowedValue>SHUFFLE</allowedValue> 
</allowedValueList> 

edefaultValue>FORWARDe/defeultValuo 

e/stateVariablo 

estate Variable sendEvents="no"> 

<name>A ARG TYPE Play Mode </name> 
edataType >stringe/dataTypo 
ealIowedValueList> 

<allowedValue>ONCE</allowedValue> 
eallowedValue>REPEATe/allowedValue> 
</allowedValueList> 

<defaultValue>REPEAT</dcfauHValuc> 

estate Variable > 
e/serviceStateTable> 
eactionList> 
<action> 

<na me >GctNumberOf Albums e/name> 
eargumentList> 
eargument> 

ename>NumAlbumse/name> 
erelatedStateVariablo 

NumAlbums 
e/relatedState'Va riab le > 
<d irection >ou t</dircctio n> 
e/argument> 
</argumentli£t> 
e/action> 
eaction> 

<namoGetAlbumIdlist</namc> 
eargumentList> 
<argumeat> 

ena me > Album IdList e/name> 
erelatedStateVariabIe> 
A ARG TYPE String 
e/relatedS tate Va riab le > 
edirection>out</direction> 
e/argumcat> 
</argumentList> 
</action> 
eaction> 

<name>GctA]bum[nfo</name> 
<argumentList> 
<argument> 

enamoAibumtd/namo 
erelatedStateVariablo 

A ARG TYPE String 
erelatedStateVariablo 
ed irection>in</d irect io n > 
e/argument> 
<argument> 

enamoFriendly Album Name</name> 
erelatedStateVariablo 

A ARG TYPE String 
e/rc la tcdS tatc Va riab le > 
edirection>oute/diiection> 
e/argument> 
eargument> 

enamoNumP icture e/na me> 
erelatedStateVariablo 

A ARG TYPE lot 
e/relatedState Va riablo 
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TABLE 7-continued 



<direction>ou t </directio n> 
</argumcnt> 
<argument> 

<name>BasePictureURL</name> 

<relatedState\ariable> 
A ARG TYPE URI 

</re la tedState Variab lc> 

<direction>out </directio ti> 
</argument> 
<argument> 

<narne>BaseFileURL</name> 

<relatedState\ariable> 
A ARG TYPE URI 

</r elatedState Variab le> 

<direction>out </directio n> 
</arguinent> 
<argument> 

<name>Prev r iewURL</name> 

<relatedState\&riable> 
A ARG TYPE URI 

</rela tedState Variab le> 

<d ircction>out</dircctio n> 
</argument> 
<argument> 

<name>PlayDirection</name> , 

<relatedState\&riable> 
A ARG TYPE PlayDirection 

</r elatedState Variab le> 

<d irection>out </directio a> 
</argument> 
<argument> 

<name;>PlayMode</aamc> 

<relatedStateVariable> 
A ARG TYPE PlayMode 

</relatedStateVariable> 

<direction>out</directioii> 
<^argumcnt> 
<argument> 

<namc> DisplayTimcScconds</aamc > 

<rela tedS tate \fr riable > 
A ARG TYPE Int 

</relatedStateVariable> 

<d irection>out</directio n> 
</argumcnt> 
</argumentList> 
<actioa> 
<action> 

<name>GetPictureInfo<name> 
<argumentList> 
<argument> 

<name>AJbumId</name> 

<relatedStatcVariablc> 
A ARG TYPE String 

</relatcd State Vartablo 

<direction>in</diiection> 
</argument> 
<argument> 

<name>PictureNumber<name> 

<rclatedState\ariable> 
A ARG TYPE int 

</relatedState Vartablo 

<dircction>in</dircction> 
</argument> 
<argumcnt> 

<narne>ActualPictureWidth</name> 

<relatedState\feriable> 
A ARG TYPE Int 

</related State Vartablo 

<dircction>out</dircctioa> 
</argument> - - - - ■ - 

<argument> 

<name>ActualPicture Height </name> 

< rela tedS tate Va riab I e > 
A ARG TYPE Int 

•c/relatedState Vartablo 

<direction>out</direction> 



TABLE 7-continued 



</argument> 
<argumcnt> 

<na me > ActaalPictureColorD ep th </na me> 
<relatedState\&riable> 

A ARG TYPE int 
</relatedS tate Variab le > 
<dircction>out<^dircction> 
</argument> 
<argument> 

<name >PictureFiIe Name </name> 
<relatedState Variab le> 

A ARG TYPE String 
</re latedS tate Va riab le > 
<direction>out-«^directio n> 
</argument> 
<argument> 

<name >PicturcTakcnTime<yname> 
<relatedS tate Variab le > 

A ARG TYPE String 
<re latedS tate Variab le> 
<direction >ou t</directio n> 
</argument> 
<argument> 

<na me >Pictu reTitle</name> 
<re latedS tate Variable > 
A ARG TYPE String 
</re latedS ta te Variab le> 
<direction >ou t<^directio n> 
</argument> 
<argument> 

<name>PictureAuthor/name> 
<relatedS tate Variab le> 

A ARG TYPE String 
•crelatedS tate Variab le> 
<direction>out</direction> 
</argument> 
<;argument> 

<name>PictureSubject</name> 
<rclatedS tate Variab 1 c > 

A ARG TYPE String 
</re latedS ta te Va riab le > 
<direction^outVdirectian> 
</argument> 
<argument> 

<name>PictureURL</name> 
<re latedS tate Variab le> 
A ARG TYPE URI 
</relatedState Variab le> 
<direction >ou t-^/dircctio n> 
</argument> 
</argumentList> 
</action> 
</actionList> 
</scpd> 



[0057] As is known by those of skill in the art, a control 
point can use a URL to request specific information from a 
device. The URL is constructed to reflect- the information 
sought and it is sent to the device using an HTTP "get" 
command. Thus, a URL can be constructed by the control 
point implemented in EPF 124 to request a picture, based on 
the "BasePictureURL" argument, of the form: http://host- 
:port/localInfo, where the host is the machine name of 
computing device 20 and the port is the port on computing 
device 20 through which UPnP communications are being 
exchanged. Locallnfo can be of the form: ssisapi.dll? Albu- 
mId-_&PictureNum-_&Width-_&Height-_&Col- 
orDeptb-_&ScaleS malllmages-_where the "Albumld" is 
the identifier of the album, the " Picture Num" is the number 
of the picture requested within the album, the "Width", 
"Height", and "Color Depth" are the maximum width, 
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height, and pixel depth abilities of the display device, such 
as EPF 124, and "ScaleSmalllmages" is a binary value 
which can allow images smaller than the requested width 
and height to be scaled appropriately. 

[0058] The exemplary service description page of Table 7 
also contains state variables, including: "A_ARG_TYPE_S- 
tring", "A_ARG_TYPE_URI" and "A_ARG_TYPE_Int", 
which are of type String, Uri, and Int (or Integer), respec- 
tively. Some state variables can be evented so that a change 
in that variable can be automatically communicated by the 
device to any control point that has subscribed to the 
eventing service, without the need for the control point to 
specifically request the value of the state variable. The 
exemplary service description of Table 7 provides for three 
state variables that can be evented: "Num Albums", which 
can indicate the number of albums available on the "Picture 
Sharer" device at a current time, "AlbumldList", which can 
be a comma delimited list of all of the album IDs published 
by the " Picture Sharer" device at a current time, and 
"LastChanged Album", which can indicate the last album 
that was modified. 

[0059] Turning to FIG. 6, an exemplary series of com- 
munications are shown between the EPF 124, implemented 
as a control point 204, and the computing device 20, hosting 
the Picture Sharer as a device 200. The PictureSharerService 
is shown as a service 202 in FIG. 6. Initially, the device 200 
can advertise its services at step 210 by sending a device 
description page, such as the one shown in Table 7. The 
control point 204 can then, at step 211, request the service 
information page, such as the exemplary PictureSharerSer- 
vice page shown in Table 7, which will be returned to it in 
step 212. As explained above, the PictureSharerService 
exposes a function "GetAlbumldList", which the control 
point 204 can call at step 213 to obtain a list of available 
albums from the Picture Sharer device 200. which can be 
returned at step 216. To more effectively present the list of 
albums available to the user, the control point 204 can, at 
step 217, perform a "GetAlbumlnfo" request on each album 
ID contained within the returned list. In this manner, the 
control point 204 can learn the names of each of the albums 
and present the user with their names, rather than their 
numeric identifiers, which can be meaningless to the user. 
When the device 200 returns the information of each album 
at step 218, a user interface 230 at the control point 204 can 
be created and presented to the user to allow the user to 
select which albums of images are to be displayed on the 
EPF 124. Once the user has elected the albums to be 
displayed, the control point 204 can request those albums at 
step 219, such as with an HTTP "get" command to the 
"BasePictureURL" as described above, and the device can 
return the images, at step 220, in the requested format, to the 
EPF 124 for display. 

[0060] The present invention further contemplates a user 
interface, such as the user interface 230 of FIG. 6, that 
allows a user to select the categories of information to be 
presented to the user from any given information presenta- 
tion appliance. FIG. 7 illustrates an exemplary user interface 
230 contemplated by the present invention. On an initial 
screen 231, the user can be presented with the names of any 
information categories that the information presentation 
appliance can present to the user. For purposes of illustra- 
tion, FIG. 7 shows an exemplary user interface of the EPF 
124. The initial screen 231 contains categories of images or 



video clips that are available for display on the EPF 124, 
including a "family" category represented by button 232, a 
"friends" category represented by button 233, a "vacations" 
category represented by button 234, a "business" category 
represented by button 235, a "baby" category represented by 
button 236, and a "wedding" category represented by button 
237. An additional button 238 allows the user access to 
additional options. The categories provided on the initial 
screen 231 could have been derived from a Picture Sharer 
device, as described in detail above, or they can be generic 
categories which, once selected by the user, can be incor- 
porated into the device description page of the EPF 124 
using an extended schema contemplated by the present 
invention, as was described in detail earlier. 

[0061] To facilitate multiple selection, the selection of a 
single category, such as category 235, can present a new 
screen 240 with the selected category highlighted. Once the 
user has completed all of their selections, the device can 
obtain the appropriate images or video clips. Alternatively, 
the user can select the "more options" button 238 and can be 
presented with a screen such as screen 250, containing 
additional options, including a "search" button 251, a 
"block" button 252, a "keywords" button 253, and a "set- 
tings" button 254. Also, a "home" button 255 is provided to 
allow the user to return to the previous screen. The exem- 
plary functionality described in detail earlier, such as allow- 
ing the user to define images through keywords, or use 
keywords to block specific types of images from being 
delivered to the EPF 124 can be accessed through a screen 
such as screen 250. The selection of one of the options, such 
as "keywords" button 253 can cause the display of a user 
entry screen, such as screen 260, containing an input box 
261 in addition to buttons 262 and 263, allowing the user to 
enter their input or cancel their input, respectively. The 
selection of either button 262 or 263 will allow the user to 
return to the previous screen 250. The user's interaction with 
the EPF 124 can be through any number of hardware and 
software devices, including a mouse 17, or a keyboard 18, 
as shown in FIG. 1, or though a touch-screen, a jog-dial,^ 
similar device, which are not shown. 

[0062] Returning to FIG. 3, each of the information 
appliances shown, including stereos 122 and 130, EPFs 124, 
126, and 132, and televisions 120, 128, and 134 can operate 
in a similar manner to that described above. The present 
invention is not intended to be limited to image presentation 
appliances, such as EPF 124. Rather, it is intended to be used 
with any appliance capable of presenting information to the 
user. For example, a stereo, such as stereos 122 and 130 can 
present aural information to a user by playing sound files 
obtained from the computing device 20 such as from the 
audio store 44 on hard disk 60, or through the broadband 
Internet connection 112, including downloaded files and 
streaming audio files, such as through Internet radio stations. 
As described above, the stereos 122 or 130 can act as either 
a UPnP device or a control point. If the stereos 122 or 130 
act as a UPnP device, then, using an extended schema 
contemplated by the present invention, such as the extended 
schema shown in Table 3, the stereos 122 or 130 can allow 
a user to input different categories or keywords of songs the 
user wishes to be played through stereos 122 or 130. The 
stereos 122 or 130 can then create an appropriate device 
description document, using the extended schema, to com- 
municate the user's selections to control points on the UPnP 
network 4. The computing device 20, acting as a control 
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point, can then obtain control over stereos 122 or 130 and 
send sound data to them if the control point contains, in local 
storage 44, or though a WAN, such as the Internet 50, the 
categories of songs that the user has selected. Alternatively, 
if the stereos 122 or 130 act as a UPnP control point, then 
they can search for devices on the UPnP network 4 that can 
serve audio information, such as a "Song Sharer" applica- 
tion operating on the computing device 20. The stereos 122 
or 130 can then request the service description page of the 
"Song Sharer" application, and can further determine, as 
described in detail above, the categories of songs that can 
then be presented to the user. Based on the user's selections, 
the stereos 122 or 130 can then, through appropriate func- 
tions calls and appropriately constructed HTTP "get" com- 
mands, request that the "Song Sharer" application deliver 
the audio data to the stereos for playback. 

[0063] As can be seen, the present invention provides for 
a method, system, and apparatus for allowing a user to tune 
the categories of information presented to the user through 
individual information presentation appliances. In addition 
to the embodiments described above, the present invention 
can be used for many various applications. For example, an 
EPF 126 in a kitchen 104 can be^tuned to present only 
coupons, allowing the user to send such information to the 
location where it most likely to be used. If a coupon is 
displayed that matches an item on the user's shopping list, 
the user can request that the EPF 126 print the coupon on 
printer 116. Additionally, the user can tune a television 128 
in the kid's bedroom 110 to prevent the television from 
displaying R-rated movies, or any adult content. The present 
invention contemplates the use of standard UPnP devices 
and XMLschemas for those devices as the basis upon which 
the extensions described above can be added to enable the 
functionality contemplated by the present invention. 

[0064] All of the references cited herein, including pat- 
ents, patent applications, and publications, are hereby incor- 
porated in their entireties by reference. 

[0065] In view of the many possible embodiments to 
which the principles of this invention may be applied, it 
should be recognized that the embodiment described herein 
with respect to the drawing figures is meant to be illustrative 
only and should not be taken as limiting the scope of 
invention. For example, those of skill in the art will recog- 
nize that the elements of the illustrated embodiment shown 
in software may be implemented in hardware and vice versa 
or that the illustrated embodiment can be modified in 
arrangement and detail without departing from the spirit of 
the invention. Therefore, the invention as described herein 
contemplates all such embodiments as may come within the 
scope of the following claims and equivalents thereof. 

We claim: 

1. A method of tuning an information presentation appli- 
ance comprising: 

receiving user input specifying categories of information 
to be presented; 

creating a device description page using a markup lan- 
guage; 

storing the categories of information in the device 
description page; and 

transmitting the device description page with the catego- 
ries of information through a network. 



2. The method of claim 1 wherein the information pre- 
sentation appliance conforms to a Universal Plug and Play 
device architecture. 

3. The method of claim 1 wherein the markup language is 
text-based. 

4. The method of claim 1 wherein the markup language 
identifies an element with a tag, and wherein the tag is 
defined in a schema. 

5. The method of claim 1 wherein an information pre- 
sented by the information presentation appliance is an audio 
information. 

6. The method of claim 1 wherein an information pre- 
sented by the information presentation appliance is a video 
information. 

7. A method of tuning an information presentation appli- 
ance comprising: 

receiving a device description page written in a markup 
language; 

parsing the device description page to identify available 
categories of information; 

presenting the available categories of information to a 
user; 

receiving user input specifying selected categories of 
information; and 

invoking a deliver function referenced by a service 
description page to receive an element of information 
belonging to the selected categories of information. 

8. The method of claim 7 wherein the information pre- 
sentation appliance conforms to a Universal Plug and Play 
control point architecture. 

9. The method of claim 7 wherein the markup language is 
text-based. 

10. The method of claim 7 wherein an information 
presented by the information presentation appliance is an 
audio information. 

11. The method of claim 7 wherein an information pre- 
sented by the information presentation appliance is a video 
information. 

12. The method of claim 7 wherein the parsing the device 
description page to identify the available categories of 
information comprises: 

identifying a service description page pointer to the 
service description page; 

requesting the service description page using the service 
description page pointer; and 

parsing the service description page to identify the avail- 
able categories of information 

13. The method of claim 12 wherein the parsing the 
service description page to identify the available categories 
of information comprises: 

identifying a list function pointer to a list function, 
wherein the list function lists the available categories of 
information; and 

invoking the list function to list the available categories of 
information using the list function pointer. 
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14. The method of claim 13 wherein the invoking the list 
function to list the available categories of information com- 
prises: 

receiving a list of identifiers of the available categories of 
information; 

identifying a name function pointer to a name function, 
wherein the name function provides names for the 
available categories of information; and 

invoking the name function for each identifier in the list 
of identifiers. 

15. An information presentation appliance comprising: 
a user input device; 

a processing unit for performing steps comprising: creat- 
ing a device description page written in a markup 
language and containing categories of information 
specified by a user through the user input device; 

a memory storage for performing steps comprising: stor- 
ing the device description page; and 

a network connection for performing steps comprising: 
transmitting the device description page. 

16. The information presentation appliance of claim 15 
wherein the information presentation appliance conforms to 
a Universal Plug and Play device architecture. 

17. The information presentation appliance of claim 15 
wherein the information presentation appliance is an elec- 
tronic picture frame. 

18. The information presentation appliance of claim 15 
wherein the information presentation appliance is a speaker. 

19. The information presentation appliance of claim 15 
wherein the information presentation appliance is a decoder 
device. 

20. The information presentation appliance of claim 15 
wherein the markup language is text-based. 

21. The information presentation appliance of claim 15 
wherein the markup language identifies an element with a 
tag, and wherein the tag is defined in a schema. 

22. The information presentation appliance of claim 15 
wherein the categories of information in the device descrip- 
tion page are identified with extended tags, and wherein the 
extended tags are defined in an extended schema. 

23. An information presentation appliance comprising: 

a network connection for performing steps comprising: 
receiving a device description page written in a markup 
language; 

a user input device for performing steps comprising: 
receiving user input specifying selected categories of 
information; and 

a processing unit for performing steps comprising: 

parsing the device description page to identify available 
categories of information; and 

invoking a deliver function referenced by a service, 
description page to receive an element of informa- 
tion belonging to the selected categories of informa- 
tion. 

24. The information presentation appliance of claim 23 
wherein the information presentation appliance conforms to 
a Universal Plug and Play control point architecture. 



25. The information presentation appliance of claim 23 
wherein the information presentation appliance is an elec- 
tronic picture frame. 

26. The information presentation appliance of claim 23 
wherein the information presentation appliance is a speaker. 

27. The information presentation appliance of claim 23 
wherein the information presentation appliance is a decoder 
device 

28. The information presentation appliance of claim 23 
wherein the markup language is text-based. 

29. The information presentation appliance of claim 23 
wherein the available categories of information include the 
selected categories of information. 

30. The information presentation appliance of claim 23 
wherein the step of parsing the device description page to 
identify the available categories of information further com- 
prises the steps of: 

identifying a service description page pointer to the 
service description page; 

requesting the service description page using the service 
description page pointer; and 

parsing the service description page to identify the avail- 
able categories of information 

31. The information presentation appliance of claim 30 
wherein the step of parsing the service description page to 
identify the available categories of information further com- 
prises the steps of: 

identifying a list function pointer to a list function, 
wherein the list function lists the available categories of 
information; and 

invoking the list function to list the available categories of 
information using the list function pointer. 

32. The information presentation appliance of claim 31 
wherein the step of invoking the list function to list the 
available categories of information further comprises the 
steps of: 

receiving a fist of identifiers of the available categories of 
information; 

identifying a name function pointer to a name function, 
wherein the name function provides names for the 
available categories of information; and 

invoking the name function for each identifier in the list 
of identifiers. 

33. A computer-readable medium having computer-ex- 
ecutable instructions for tuning an information presentation 
appliance, the computer-executable instructions performing 
steps comprising: 

receiving user input specifying categories of information 
to be presented; 

creating a device description page using a markup lan- 
guage; 

storing the categories of information in the device 
description page; and 

transmitting the device description page with the catego- 
ries of information through a network. 

34. The computer-readable medium of claim 33 wherein 
the information presentation appliance conforms to a Uni- 
versal Plug and Play device architecture. 
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35. The computer-readable medium of claim 33 informa- 
tion presentation appliance is an electronic picture frame. 

36. The computer-readable medium of claim 33 wherein 
the markup language is text-based. 

37. The computer-readable medium of claim 33 wherein 
the markup language identifies an element with a tag, and 
wherein the tag is defined in a schema. 

38. The computer-readable medium of claim 33 wherein 
the categories of information in the device description page 
are identified with extended tags, and wherein the extended 
tags are defined in an extended schema. 

39. A computer-readable medium having computer-ex- 
ecutable instructions for tuning an information presentation 
appliance, the computer-executable instructions performing 
steps comprising: 

receiving a device description page written in a markup 
language; 

parsing the device description page to identify available 
categories of information; 

presenting the available categories of information to a 
user; 

receiving user input specifying selected categories of 
information; and 

invoking a deliver function referenced by a service 
description page to receive an element of information 
belonging to the selected categories of information. 

40. The computer-readable medium of claim 39 wherein 
the information presentation appliance conforms to a Uni- 
versal Plug and Play control point architecture. 

41. The computer-readable medium of claim 39 wherein 
the information presentation appliance is an electronic pic- 
ture frame. 

42. The computer-readable medium of claim 39 wherein 
the markup language is text-based. 



43. The computer-readable medium of claim 39 wherein 
the available categories of information include the selected 
categories of information. 

44. The computer-readable medium of claim 39 wherein 
the parsing the device description page to identify the 
available categories of information comprises: 

identifying a service description page pointer to the 
service description page; 

requesting the service description page using the service 
description page pointer; and 

parsing the service description page to identify the avail- 
able categories of information 

45. The computer-readable medium of claim 44 wherein 
the parsing the service description page to identify the 
available categories of information comprises: 

identifying a list function pointer to a list function, 
wherein the list function lists the available categories of 
information; and 

invoking the list function to list the available categories of 
information using the list function pointer. 

46. The computer-readable medium of claim 45 wherein 
the invoking the list function to list the available categories 
of information comprises: 

receiving a list of identifiers of the available categories of 
information; 

identifying a name function pointer to a name function, 
wherein the name function provides names for the 
available categories of information; and 

invoking the name function for each identifier in the list 
of identifiers. 
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